Method of device-to-device communications in hybrid distributed device control networks

ABSTRACT

The present invention comprises a method of source routing to implement device-to-device communications across a hybrid distributed device control network. The method is based in packet communications in which packets are structured so that they can be readily converted between communications protocols, and in which packets enclose routing information and parameters.

BACKGROUND OF INVENTION BACKGROUND RELATED APPLICATIONS

[0001] This invention uses the concepts of true distributed control anddistributed device control network of our co-pending applications. Italso uses the concepts of device controller and network-enabled devices.

BACKGROUND FIELD OF INVENTION

[0002] This invention relates to device-to-device network communicationmethods and systems, specifically to device-to-device communicationsacross a hybrid distributed device control network.

BACKGROUND DISCUSSION OF PRIOR ART

[0003] The Cambridge Dictionary of American English defines a “device”to be an object or machine invented to fulfill a particular purpose.According to the present invention, the term “device” is not limited tophysical apparati, but is considerably expanded to comprise abstract orvirtual devices, such as system operators, that partake in networkcommunications. One fundamental characteristic of devices is that theycomprise a finite set of states associated with their operation.

[0004] Source routing is packet routing in which a source node has apriori knowledge of the network path to a destination node, i.e., acomplete sequence of intermediary network nodes a packet must traverseto reach its destination. This routing information is included in theheader of every sent packet.

[0005] Source routing is implemented in many network communicationenvironments (e.g., Internet Protocol). Yet, its use is deemedinefficient for regular network package routing due to the overhead ofincreased packet header size it involves, and it is virtually neverused, except for network mapping and troubleshooting instances.

[0006] Nonetheless, the simplicity of using source routingcommunications makes it positively suitable and advantageous for someapplications, specifically hybrid distributed device control networks,since its use greatly reduces the cost and complexity of hardware logicof network routing devices and allows for faster networks.

[0007] According to the present invention, a hybrid distributed devicecontrol network comprises a set of interconnected subnetworks ofarbitrary topology, each containing several interconnected devicecontrollers and/or network-enabled devices. The term “hybrid” refers toa network that comprises several subnetworks interconnected acrossdissimilar communication media (e.g., Ethernet, RF, etc.), and usingdifferent communication protocols (e.g., LONtalk, UDP/IP, etc.).Subnetworks using incompatible protocols are interconnected at networkrouters which act as dual nodes, translating and transferring packetsbetween subnetworks and communication protocols. There are two types ofsource routing, strict and loose. In strict source routing, everyintermediary network node is explicitly specified in the packet headerat the source. In loose source routing, a set of intermediary nodesthrough which the packet must pass are specified in the packet header,but each of these may reside several hops away from one another.

[0008] Implementing a communication system over a hybrid distributeddevice control network using source routing requires simpler processingthat results in reduced implementation complexity and cost. Sourcerouting is also compatible with the philosophy of true distributedcontrol because packet routing information is contained at each nodewhere packets originate.

[0009] In the recent past, there have been several attempts to create amethod of source routing to communicate across hybrid networks (e.g.,U.S. Pat. 5,570,084). However, the resulting methods are definitelyinadequate for device-to-device communications because they do notimplement important communications services, namely, multicasting andbroadcasting, which are absolutely required for interdevicecommunications. Other attempts have been made to propose generic methodsfor routing packets in communications networks (e.g., U.S. Pat.5,353,283). However, the resulting methods either have been developedfor networks with limited topologies or cannot be used in networkscomprising subnetworks using incompatible communications protocolsand/or dissimilar communications media.

[0010] Hence, it is an object of the present invention to overcome thedisadvantages of the prior art, presenting a source routingcommunication method specifically designed for interdevice packetrouting across networks comprising different communication protocols(e.g., LONtalk, UDP/IP, etc.) and media (e.g., Ethernet, RF, etc.), andproviding several communication services.

SUMMARY OF INVENTION

[0011] The present invention comprises a method of source routing toimplement device-to-device communications across a hybrid distributeddevice control network. The method is based in packet communications inwhich packets are structured so that they can be readily convertedbetween communications protocols, and in which packets enclose routinginformation and parameters.

OBJECTS AND ADVANTAGES

[0012] Accordingly, several objects and advantages of the presentinvention are:

[0013] a) To provide a flexible method designed and developedspecifically for interdevice communications, which addresses andovercomes the limitations of existing communications methods;

[0014] b) to provide a method of source routed communications designedto fulfill requirements of device-to-device communications, whichreduces the complexity and cost of system implementation of existingcommunications methods;

[0015] c) to provide a method of device-to-device communications whichcan be used in networks independently of the network communicationprotocols and/or media used, and which indicates how a packet should betransferred and translated between networks using different networkcommunication protocols and/or media;

[0016] d) to provide a flexible method of device-to-devicecommunications which supports dynamic structuring of communicationpackets, depending on the communication services required;

[0017] e) to provide a method of device-to-device communications whichsupports one-to-many communication services, including multicasting andbroadcasting;

[0018] f) to provide a method of device-to-device communications inwhich all network nodes and routers, once configured, operateautonomously in agreement with the philosophy of true distributedcontrol; Other objects and advantages of this invention will becomeapparent from a consideration of the ensuing description and drawings.

BRIEF DESCRIPTION OF DRAWINGS

[0019] In the drawings, closely related figures have the same number butdifferent alphabetic suffixes.

[0020]FIG. 1 shows an exemplary hybrid distributed control network.

[0021]FIG. 2A illustrates a general configuration of device controllersand network-enabled devices.

[0022]FIG. 2B shows an exemplary instance of device-to-devicecommunications, between an alarmed door and an alarm siren.

[0023]FIG. 3 displays the structure of a generic network communicationspacket.

[0024]FIG. 4 comprises a simplified version of the network shown inFIG. 1. FIG. 5A illustrates the acknowledge communications service.

[0025]FIG. 5B illustrates the broadcast communications service.

[0026]FIG. 5B illustrates the multicast communications service.

[0027] The terms Type I, II and III Networks are arbitrary terms used todifferentiate between exemplary subnetworks using dissimilarcommunication protocols and media. Any network protocol type may besubstituted in their stead.

LIST OF REFERENCE NUMERALS IN DRAWINGS

[0028]10 Internetwork

[0029]12 Network Router Node (Internet to Type III Network)

[0030]14, 18 Network Router Node (Internet to Type II Network)

[0031]16 Network Router Node (Internet to Type I Network)

[0032]20 Type III Subnetwork (Wireless)

[0033]22, 26, 37 Type II Subnetwork

[0034]24 Type I Subnetwork

[0035]28, 30 Type III Network End Node

[0036]32 Network Router Node (Type III Network to Type II Network)

[0037]34, 36, 38, 40, 48, 50 Type II Network End Nodes

[0038]42, 43, 44 Type I Network End Nodes

[0039]46 Network Router Node (Type I Network to Type II Network)

[0040]210 Alarmed electric door

[0041]212 Device controller controlling

[0042]210214 Device controller controlling

[0043]216216 Alarm siren

[0044]218 Network-enabled Alarm siren

DETAILED DESCRIPTION

[0045] Now, the present invention will be described by referring to theaccompanying drawings that illustrate preferred embodiments of theinvention.

[0046]FIG. 1 illustrates an exemplary hybrid distributed device controlnetwork in which a plurality of network router nodes 12, 14, 16 and 18,hereafter referred to as routers, are connected to an internet 10. Saidrouters serve as connection links between internet 10 and a set ofsubnetworks 20, 22, 24, 26, which use dissimilar communication protocolsand/or media. In FIG. 1, subnetwork 20 is of hypothetical Type III(e.g., using radio frequency as medium), subnetworks 22 and 26 are ofhypothetical Type II (e.g., using LONtalk protocol), and subnetwork 24is of hypothetical Type I (e.g., using UDP/IP over Ethernet). There aretwo further components, namely, a subnetwork 37 and a router 46.Subnetwork 37 connects to subnetwork 20 through a router 32. Likewise,router 46 connects subnetworks 22 and 24 together.

[0047] Each said subnetwork contains a plurality of network end nodes,hereafter referred to as nodes. For instance, subnetwork 20 comprisesnodes 28 and 30; subnetwork 22 comprises nodes 38 and 40; subnetwork 24comprises nodes 42, 43 and 44;

[0048] subnetwork 26 comprises nodes 48 and 50; and subnetwork 37comprises nodes 34 and 36.

[0049] In said hybrid distributed device control network, hereafterreferred to as network, a packet originating at a source node isdirectly received at a destination node, provided both source anddestination nodes reside in the same subnetwork. For instance, a packetoriginating at source node 44 will directly reach destination node 42,within subnetwork 24.

[0050] Furthermore, a packet originating at a source node whosedestination node resides in a different subnetwork must traverse anetwork path through one or more routers to reach its destination. Forinstance, a packet originating at source node 42 must pass throughrouters 16 and 14 to reach destination node 38.

[0051] In this method, every router interconnects two subnetworks, andthus exists in two subnetworks simultaneously, transferring packets fromone subnetwork into another. Since the two subnetworks interconnected bya router use different communication protocols and/or media, it followsthat a router must have two different network addresses, one for each ofits associated subnetworks. For example, router 46 must have a Type IINetwork address seen by nodes 38 and 40 of subnetwork 22, and a Type INetwork address seen by nodes 42, 43 and 44 of subnetwork 24.

[0052] Every node in said network is either a device controller to whichseveral devices may be connected, or a network-enabled device, i.e., aconventional device with added capabilities to communicate across anetwork. FIG. 2A illustrates this.

[0053] The main functions of a device controller include controlling thestate of all conventional devices connected to it, such as modifying thedevice″s operating state (e.g., command execution, activations,deactivations, etc.), detecting an operating state change or reportingon the operating state change of a device (e.g., event reporting), amongothers. Some typical devices include electric doors, thermal sensors,GPS, video cameras, among several others. The main functions of anetwork-enabled device include reporting on its operating state, amongothers.

[0054] This invention concerns communication between device controllersand/or network-enabled devices across networks. FIG. 2B illustrates anexemplary case: an electric door 210 controlled by a device controller212 is opened. Said controller 212 detects the state change in saidelectric door 210 and sends two messages or packets across the network.The first packet reaches device controller 214, containing a command toactivate an alarm siren 216. The second packet reaches network-enabledalarm siren 218 and activates it.

[0055] In source routing, each packet or message originating at anetwork node contains packet routing information, including a list ofall network routers a packet must traverse in order to reach itsdestination node. The structure of a packet is described next, and isshown in FIG. 3.

[0056] According to the present invention, a packet consists of threefundamental sections: header, network path and data. The headers sectioncontains general information about the packet, including a packet typeand a packet identification number, among several others. The networkpath section comprises a list of all network node addresses a packetmust traverse to reach its final destination. The data section containsthe actual packet content information.

[0057] The header section contains several information fields: • PacketType (PT): a number which specifies the type of said packet, and whichindicates the type of communication services that said packet requires.Packet types include ACK (i.e., referring to a packet sent toacknowledge receipt of another packet), NO_ACK (i.e., referring to apacket comprising data which requires an ACK packet response), UNACK(i.e., referring to a packet comprising data which requires no ACKpacket response), BROADCAST (i.e., referring to a packet directed to allnodes in a given subnetwork), MULTICAST (i.e., referring to a packetdirected to some nodes in a given subnetwork), among others. Dependingon the value of this field, the structure of the packet may vary, asdescribed below. In one implementation, this field consists of one byte,allowing 255 possible packet type values.

[0058] Packet ID (PI): a number which serves as a unique identifier forsaid packet. In one implementation, this field consists of three bytes.

[0059] Quality of Service (QOS): a set of bits which specify severalnetwork parameters that modify how a package is handled by networkrouters. The most important of these parameters is packet priority. Inone implementation, this field consists of one byte.

[0060] Network Path Length (NPL): a number indicating the number ofnodes that said packet must traverse in order to reach its destination,including the source and destination nodes. In one implementation, thisfield consists of one byte.

[0061] Data Pointer (DP): a number that points to the beginning of thedata section below. Specifically, it contains the offset in bytes fromthe beginning of the packet to the beginning of the data section.

[0062] Network Path Pointer Table (NPPT): a set of fields that containpointers to entries in the Network Path section described below.Specifically, said pointers specify the offset from the beginning of thepacket to the start of every entry in the Network Path section below.The order in which network nodes are found on this table determines theorder in which network nodes will be traversed by the packet. The tablehas as many entries as specified in the Network Path Length above. Notethat to alter the network path that a message must follow you can modifythe order in which network address are pointed at by NPPT entries. Forinstance, to reverse the order of the nodes that a packet must traverse,reverse the order of the entries in the NPPT. In one implementation,each table entry consists of one byte.

[0063] Network Path Destination Index (NPDI): a number specifying thenext entry in the NPPT to which the packet should be transmitted. Forinstance, when the packet is at source node 34, this field has a valueof two (“2”), referring to the second entry in the NPPT, which points tothe address of router 32. After the packet reaches router 32, this fieldwill have a value three (“3”), referring to the third entry in NPPT,which points to the address of router 12, and so on. In oneimplementation, this field consists of one byte.

[0064] Multicast Pointer (MP): (only included if Packet Type equals“40”, in multicast packets.) This field contains a number that points tothe last router entry in the Network Path Pointer Table, which connectsto the subnetwork that contains all nodes receiving the multicastpacket. This number must be equal to or lesser than the Network PathLength specified above. In one implementation, this field consists ofone byte.

[0065] Network Path section consists of a list of at least two networkaddress entries comprising all network routers a packet must visit toreach its destination. Each entry consists of two members: a networktype identifier and a network address.

[0066] Network Type (NT): a number specifying the network type of therouter network address that follows. In one implementation, this fieldconsists of one byte.

[0067] Network Address (NA): a variable-length number specifying anetwork address to which said packet must be sent. In oneimplementation, this field consists of four bytes.

[0068] Finally, the Data section contains two fields: • Data Length(DL): a number specifying the length of the data segment contained insaid packet. In one implementation, this field consists of two bytes.

[0069] Data Segment (DS): a data segment of the above data length. Thissegment contains the actual data for which this message is sent. In theexample of FIG. 2B, the data of the packet traveling from nodes 212 to214 comprises a control command which activates the alarm sirencontrolled by node 214.

OPERATION OF INVENTION

[0070] Let there be a packet X, structured as described above, whichoriginates at a source node and travels across a network to reach adestination node. Packet X includes a network path section with acomplete list of network routers it must traverse to reach itsdestination. Although packet X comprises the exact network route it musttraverse to reach its destination, it does not contain anyprotocol-specific information. Instead, packet X is a message unit thatmust be encapsulated in a protocol-specific packet depending on thenetwork where it may circulate. Hence, each node that sends or receivespacket X must encapsulate or decapsulate packet X accordingly.

[0071]FIG. 4 is an exemplary illustration of the following descriptionof the method presented in this invention. It is a simplified version ofFIG. 1, following the same numeral pattern. A packet X is created at asource node 34 which must traverse a network to reach destination node42. Source node 34 encapsulates packet X within a packet X0, aprotocol-specific packet that can be processed by subnetwork 37 (i.e.,Type II Network). Next, source node 34 sends packet X0 out acrosssubnetwork 37 towards router 32.

[0072] Router 32 receives packet X0 and decapsulates it to retrievepacket X. Next, router 32 updates packet X″s NPDI to point to the nextdestination address in the NPPT (i.e., router 12). Next, router 32encapsulates packet X into a packet X1, following the protocol used bysubnetwork 20 (i.e., Type III Network), and sends packet X1 out acrosssubnetwork 20 towards router 12.

[0073] Router 12 receives packet X1 and decapsulates it to retrievepacket X. Next, router 12 updates packet X″s NPDI to point to the nextdestination address in the NPPT (i.e., router 16). Next, router 12encapsulates packet X into a packet X2, following the protocol used byan internet 10, and sends packet X2 out across internet 10 towardsrouter 16.

[0074] Router 16 receives packet X2 and decapsulates it to retrievepacket X. Next, router 16 updates packet X″s NPDI to point to the nextdestination address in the NPPT (i.e., node 42). Next, router 16encapsulates packet X into a packet X3, following the protocol used bysubnetwork 16 (i.e., Type I Network), and sends packet X3 out acrosssubnetwork 24 towards node 42.

[0075] When packet X3 is received at destination node 42, it isdecapsulated and packet X is retrieved from it. Node 42 processes thedata section of packet X.

[0076] To summarize, a packet originates at a source node and comprisesan exact network path that the packet must traverse. Such packet is sentthrough all nodes and routers comprised in the packet″s network pathsection. The packet is encapsulated, and the destination address isincluded in the encapsulation headers. Then, the encapsulated packet isdecapsulated. This process is repeated until the packet passes throughall required subnetworks of dissimilar communications protocols andmedia. At each network router, the packet is modified accordingly sothat its NPDI points to the next destination that the packet must reach.The rest of the contents of the packet remains untouched. Once itreaches its final destination node, the packet″s data section isprocessed.

[0077] The above is a description of the basic communication method,assuming the simplest type of communication service, namely, forwardtransmission demanding no reply. The method varies according to the typeof communication service specified in the packet″s Packet Type field.These variations are described next.

[0078] If the type of communications service requires a response fromthe destination node, then a return or backward path to source node 34must be known by destination node 42. Note that in the basic methodabove, destination node 42 cannot retrieve the return path towardssource node 34 from packet Ax″s headers. For instance, packet X onlycontains router 16's address as seen by internet 10, and does notcontain router 16's address as seen by subnetwork 24.

[0079] The type of communications in which a source node requires aresponse from a destination node is described next. This is referred toas Response communications service. When a router receives a packet fromone of its two interconnecting subnetworks, it modifies the packet″snetwork address path list (NT and NA fields) substituting the routeraddress as seen by its sending subnetwork for the router address as seenby its receiving subnetwork. For instance, in FIG. 4A, when packet Xleaves node 34 and reaches router 32, it contains router 32's address asseen by subnetwork 37 (i.e., receiving subnetwork). Router 32, then,replaces said address by router 32's address as seen by subnetwork 20(i.e., sending subnetwork), and transmits packet X to router 12. Whenpacket X reaches router 12, its network address path contains router12's address as seen by subnetwork 20. Router 12, then, replaces saidaddress by router 12 s address as seen by internet 10, and transmitspacket X to router 16. This substitution recurs at every router found onpacket X″s network path. Once packet X reaches destination node 42, itsnetwork path section contains all router addresses as seen from node42's perspective, thus, allowing it to reach source node 34, when aresponse is necessary.

[0080] When said destination node needs to send a response packet out tosaid source node, it may copy the structure of the received packet X,invert the entries of the NPPT (so that the network path is reversed),set the appropriate header fields (e.g., PT, NPDI, QOS, etc.), andenclose the corresponding data segment. Hence, this show that processingrequired for generating response packets is minimal.

[0081] In a second type of communications service, the Acknowledge (ACK)communications service, it is desired that responses be sent back from adestination node to a source node to acknowledge receipt of a packet. Inthese circumstances, if acknowledgement messages are not received at thesource node within a time frame, the source node may resend the packet.An instance of this type of communication services is illustrated inFIG. 5A (for Packet Type equal to “50”). Source node 34 generates packetX of said type and sends it to destination node 42 (step 1). Uponreceiving packet X, router 32 sends an ACK packet (Packet Type equals“51”) to source node 34 (step 2, ACK0). Then, packet X travels to nodes12 and 16 (steps 3, 4 and 5). Once destination node 42 receives packetX, another ACK packet is sent back to source node 34 (step 6, ACK1).Thus, only upon receipt of both ACK0 and ACK1 packets does source node34 consider packet X transmission successful. Otherwise, source node 34may resend packet X.

[0082] In the Broadcast communications service, the purpose is to send apacket that will be broadcast to all nodes connected to a givensubnetwork. A broadcast packet is structured as described above. ThePacket Type field is set to “45”, and the destination node networkaddress is set to a broadcast indicator (i.e., all address bytes are setto “255”). After said broadcast packet leaves a source node, ittraverses a set of network routers, and then is broadcast into asubnetwork by the last router in the network path. FIG. 5B illustratesan instance of broadcast. In FIG. 5B, node 34 generates a broadcastpacket destined for subnetwork 24. Said broadcast packet leaves node 34and traverses all intermediate subnetworks (i.e., 32, 12 and 16) asdescribed above. When router 16 checks the network path section of thebroadcast packet and finds an address consisting of “255” numerals, itencapsulates it into a protocol-specific broadcast packet and sends itout to subnetwork 24.

[0083] In the Multicast communications service (i.e., Packet Type equals“40”), the purpose is to send a packet that will reach many but not allnodes contained in a specific subnetwork. FIG. 6C illustrates aninstance of this service, where a multicast packet X leaves node 34 andreaches nodes 42 and 44, but does not reach node 43. The header sectionof multicast packets comprises an extra Multicast Pointer field, asdescribed above, that specifies the NPPT entry that points to theaddress of the end router in the network path which must send themulticast packet (e.g., router 16 of FIG. 6C). Multicast packet Xtraverses the network path exactly as any other packet until it reachesthe router specified by Multicast Pointer (e.g., router 16). If thesubnetwork where multicast packet X must be sent out (e.g., subnetwork24) supports multicasting, said router encapsulates said packet X insidea protocol-specific multicast packet and sends it out. If saidsubnetwork does not support multicasting, said router will retrieve allmulticast target addresses from the network address section of packet X(e.g., nodes 42 and 44) and transmit a protocol-specific encapsulatedpacket to each specified destination. In the instance of FIG. 6C, incase subnetwork 24 does not support multicasting router 16 will sendcopies of packet X to nodes 42 and 44, as specified in the networkaddress section of packet X.

Conclusion, Ramifications and Scope of Invention

[0084] Thus, the reader will see that the present method ofdevice-to-device communications provides a flexible method of sourcerouted communications designed to fulfill requirements of interdevicecommunication which solves all limitations of existing methods. Thiscomprehensive method can be used in any network independently of theassociated communication protocol and/or media, reduces the complexityand cost of system implementation of existing communications methods,and supports one-to-many interdevice communication.

[0085] While our above description contains many specificities, theseshould not be construed as limitations to the scope of the invention,but rather as an exemplification of one preferred embodiment thereof.Obviously, modifications and alterations will occur to others upon areading and understanding of this specification such as, for example,several possible variations to the presented packet structure to includeother network routing parameters, several variations to the presentedcommunications services, especially to different modes of theAcknowledge communications service. The description above is intended,however, to include all such modifications and alterations insofar asthey come within the scope of the appended claims or the equivalentsthereof.

What is claimed is:
 1. A method of source routing to implementdevice-to-device communications across a hybrid distributed devicecontrol network, said method comprising: a) orginating a packet at asource node; b) having the packet consist of sections including; i) aheader; ii) a network path; and iii) data. c) encapsulating the packetin a protocol-specific packet used by the subnetwork of the source node;d) passing said protocol-specific packet to the first destination routerin the network path; e) having the router decapsulate theprotocol-specific packet; f) increment the next path destination indexcounter by one; g) using the next path destination index counter topoint to the next path destination address; h) encapsulating the packetin a protocol-specific packet used by the next destination subnetwork;i) passing said protocol-specific packet to the next destination routerin the network path; and j) repeating the previous five steps until thepacket reaches the final destination node.
 2. The method according toclaim 1 wherein said encapsulation packet has an encapsulation headerthat contains a destination address.
 3. The method according to claim 1wherein an acknowledgement is requested comprising the additional stepsof: k) orginating an acknowledgement packet at the destination node; l)having the acknowledgement packet consist of sections including; i) aheader; ii) a network path; and iii) data. m) creating theacknowledgement network path by inversing the network path of thepacket; n) encapsulating the acknowledgement packet in aprotocol-specific packet used by the subnetwork of the destination node;o) passing said protocol-specific packet to the first destination routerin the acknowledgement network path; p) having the router decapsulatethe protocol-specific packet; q) increment the next path destinationindex counter by one; r) using the next path destination index counterto point to the next path destination address; s) encapsulating theacknowledgement packet in a protocol-specific packet used by thedestination address″s subnetwork; t) passing said protocol-specificpacket to the next destination router in the network path; and u)repeating the previous five steps until the acknowledgement packetreaches the source node.
 4. The method according to claim 1 wherein apacket is being broadcast to all the nodes in a subnetwork in which theadditional steps of: k) identifying the packet as a broadcast packet;and l) encapsulating the broadcast packet in a protocol-specific packetused by the destination subnetwork; and m) passing said broadcast packetto the nodes on the destination subnetwork.
 5. The method according toclaim 1 wherein a packet is a multicast to the nodes in a specificsubnetwork in which the additional steps of: k) identifying the packetas a multicast packet; l) checking to see if the subnetwork supportsmulticasting; m) encapsulating the multicast packet in aprotocol-specific packet used by the subnetwork and pass said multicastpacket to all of the nodes in the subnetwork if the subnetwork supportsmulticasting; and n) encapsulating the multicast packet in aprotocol-specific packet used by the subnetwork and pass said multicastpacket to the the nodes specified in the network address section of thepacket, if the subnetwork does not support multicasting.
 6. The methodaccording to claim 1 wherein said packet helder section contains thefollowing fields: a) Packet Type; b) Packet ID; c) Quality of Service;d) Network Path Length; e) Data Pointer; f) Network Path Pointer Table;g) Network Path Destination Index; and h) Multicast Pointer.
 6. Themethod according to claim 1 wherein said Network Path section containsthe following fields: a) Network Type; and b) Network Address.
 7. Themethod according to claim 1 wherein said Data section contains thefollowing fields: a) Data Length; and b) Data Segment.